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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3 GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, 
etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 

The present document specifies the E-UTRA Radio Link Control (RLC) protocol for the UE - E-UTRAN radio interface. 
The specification describes: 

- E-UTRA RLC sublayer architecture; 

- E-UTRA RLC entities; 

services expected from lower layers by E-UTRA RLC; 

- services provided to upper layers by E-UTRA RLC; 

- E-UTRA RLC functions ; 

- elements for peer-to-peer E-UTRA RLC communication including protocol data units, formats and parameters; 

- handling of unknown, unforeseen and erroneous protocol data at E-UTRA RLC. 

2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3 GPP document (including a 
GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TR 2L905: "Vocabulary for 3GPP Specifications". 

[2] 3GPP TS 36.300: "E-UTRA and E-UTRAN Overall Description; Stage 2". 

[3] 3GPP TS 36.321: "E-UTRA MAC protocol specification". 

[4] 3GPP TS 36.323: "E-UTRA PDCP specification". 

[5] 3GPP TS 36.33 1 : "E-UTRA RRC Protocol specification" . 

3 Definitions, symbols and abbreviations 
3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 2L905 [1] and the following apply. A 
term defined in the present document takes precedence over the definition of the same term, if any, in TR 2L905 [1]. 

byte segment: A byte of the Data field of an AMD PDU. Specifically, byte segment number corresponds to the first 
byte of the Data field of an AMD PDU. 

Data field element: An RLC SDU or an RLC SDU segment that is mapped to the Data field. 

RLC SDU segment: A segment of an RLC SDU. 
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3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

AM Acknowledged Mode 

AMD AM Data 

ARQ Automatic Repeat reQuest 

BCCH Broadcast Control CHannel 

BCH Broadcast CHannel 

CCCH Common Control CHannel 

DCCH Dedicated Control CHannel 

DL DownLink 

DL-SCH DL-Shared CHannel 

DTCH Dedicated Traffic CHannel 

E Extension bit 

eNB E-UTRAN Node B 

E-UTRA Evolved UMTS Terrestrial Radio Access 

E-UTRAN Evolved UMTS Terrestrial Radio Access Network 

FI Framing Info 

HARQ Hybrid ARQ 

LI Length Indicator 

LSF Last Segment Flag 

MAC Medium Access Control 

MCCH Multicast Control CHannel 

MTCH Multicast Traffic CHannel 

PCCH Paging Control CHannel 

PDU Protocol Data Unit 

RLC Radio Link Control 

RRC Radio Resource Control 

SAP Service Access Point 

SDU Service Data Unit 

SN Sequence Number 

SO Segment Offset 

TB Transport Block 

TM Transparent Mode 

TMD TM Data 

UE User Equipment 

UL UpLink 

UM Unacknowledged Mode 

UMD UM Data 



General 



4.1 



Introduction 



The objective is to describe the RLC architecture and the RLC entities from a functional point of view. 



4.2 



RLC arciiitecture 



4.2.1 RLC entities 

The description in this sub clause is a model and does not specify or restrict implementations. 

RRC is generally in control of the RLC configuration. 

Functions of the RLC sub layer are performed by RLC entities. For a RLC entity configured at the eNB, there is a peer 
RLC entity configured at the UE and vice versa. 
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An RLC entity receives/delivers RLC SDUs from/to upper layer (i.e. RRC for CCCH, PDCP otherwise) and 
sends/receives RLC PDUs to/from its peer RLC entity via lower layers (i.e. MAC and physical layer). An RLC PDU can 
either be a RLC data PDU (see sub clause 6.1.1) or a RLC control PDU (see sub clause 6.2.1). If an RLC entity receives 
RLC SDUs from upper layer, it receives them through a single SAP between RLC and upper layer, and after forming RLC 
data PDUs from the received RLC SDUs, the RLC entity delivers the RLC data PDUs to lower layer through a single 
logical channel. If an RLC entity receives RLC data PDUs from lower layer, it receives them through a single logical 
channel, and after forming RLC SDUs from the received RLC data PDUs, the RLC entity delivers the RLC SDUs to 
upper layer through a single SAP between RLC and upper layer. If an RLC entity delivers/receives RLC control PDUs 
to/from lower layer, it delivers/receives them through the same logical channel it delivers/receives the RLC data PDUs 
through. 

An RLC entity can be configured to perform data transfer in one of the following three modes: Transparent Mode (TM), 
Unacknowledged Mode (UM) or Acknowledged Mode (AM). Consequently, an RLC entity is categorized as a TM RLC 
entity, an UM RLC entity or an AM RLC entity depending on the mode of data transfer that the RLC entity is configured 
to provide. 

A TM RLC entity is configured either as a transmitting TM RLC entity or a receiving TM RLC entity. The transmitting 
TM RLC entity receives RLC SDUs from upper layer and sends RLC PDUs to its peer receiving TM RLC entity via lower 
layers. The receiving TM RLC entity delivers RLC SDUs to upper layer and receives RLC PDUs from its peer 
transmitting TM RLC entity via lower layers. 

An UM RLC entity is configured either as a transmitting UM RLC entity or a receiving UM RLC entity. The transmitting 
UM RLC entity receives RLC SDUs from upper layer and sends RLC PDUs to its peer receiving UM RLC entity via 
lower layers. The receiving UM RLC entity delivers RLC SDUs to upper layer and receives RLC PDUs from its peer 
transmitting UM RLC entity via lower layers. 

An AM RLC entity consists of a transmitting side and a receiving side. The transmitting side of an AM RLC entity 
receives RLC SDUs from upper layer and sends RLC PDUs to its peer AM RLC entity via lower layers. The receiving 
side of an AM RLC entity delivers RLC SDUs to upper layer and receives RLC PDUs from its peer AM RLC entity via 
lower layers. 

Figure 1 illustrates the overview model of the RLC sub layer. 
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Figure 4.2.1-1 : Overview model of the RLC sub layer 

The following appHes to all RLC entity types (i.e. TM, UM and AM RLC entity): 

RLC SDUs of variable sizes which are byte aligned (i.e. multiple of 8 bits) are supported; 
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RLC data PDUs are formed from RLC SDUs received from upper layer only when a transmission opportunity has 
been notified by lower layer (i.e. by MAC) and are then delivered to lower layer; 

RLC control PDUs are formed within RLC only when a transmission opportunity has been notified by lower layer 
(i.e. by MAC) and are then delivered to lower layer. 

Description of different RLC entity types are provided below. 

4.2.1.1 TM RLC entity 

4.2.1.1.1 General 

A TM RLC entity can be configured to deliver/receive RLC PDUs through the following logical channels: 
- BCCH, DL/UL CCCH and PCCH. 
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Figure 4.2.1.1.1-1 : Model of two transparent mode peer entities 

A TM RLC entity delivers/receives the following RLC data PDU: 
- TMD PDU. 

4.2.1 .1 .2 Transmitting TIVI RLC entity 

When a transmitting TM RLC entity forms TMD PDUs from RLC SDUs, it shall: 
not segment nor concatenate the RLC SDUs; 
not include any RLC headers in the TMD PDUs. 

4.2.1 .1 .3 Receiving TIVI RLC entity 

When a receiving TM RLC entity receives TMD PDUs, it shall: 

deHver the TMD PDUs (which are just RLC SDUs) to upper layer. 

4.2.1.2 UM RLC entity 

4.2.1.2.1 General 

An UM RLC entity can be configured to deliver/receive RLC PDUs through the following logical channels: 
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DL/UL DCCH, DL/UL DTCH, MCCH or MTCH. 
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Figure 4.2.1.2.1-1 : Model of two unacknowledged mode peer entities 

An UM RLC entity delivers/receives the following RLC data PDU: 
- UMD PDU. 

4.2.1 .2.2 Transmitting UIVI RLC entity 

When a transmitting UM RLC entity forms UMD PDUs from RLC SDUs, it shall: 

segment and/or concatenate the RLC SDUs so that the UMD PDUs fit within the total size of RLC PDU(s) indicated 
by lower layer at the particular transmission opportunity notified by lower layer; 

include relevant RLC headers in the UMD PDU. 

4.2.1 .2.3 Receiving UIVI RLC entity 

When a receiving UM RLC entity receives UMD PDUs, it shall: 

detect whether or not the UMD PDUs have been received in duplication, and discard duplicated UMD PDUs; 

reorder the UMD PDUs if they are received out of sequence; 

detect the loss of UMD PDUs at lower layers and avoid excessive reordering delays; 

reassemble RLC SDUs from the reordered UMD PDUs (not accounting for RLC PDUs for which losses have been 
detected) and deliver the RLC SDUs to upper layer in sequence; 

discard received UMD PDUs that cannot be re-assembled into a RLC SDU due to loss at lower layers of an UMD 
PDU which belonged to the particular RLC SDU. 

At the time of RLC re-establishment, the receiving UM RLC entity shall: 
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if possible, reassemble RLC SDUs from the UMD PDUs that are received out of sequence and deliver them to upper 
layer; 

discard any remaining UMD PDUs that could not be reassembled into RLC SDUs; 

initialize relevant state variables and stop relevant timers. 

4.2.1.3 AM RLC entity 

4.2.1.3.1 General 

An AM RLC entity can be configured to deliver/receive RLC PDUs through the following logical channels: 
- DL/UL DCCH or DL/UL DTCH. 
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Figure 4.2.1.3.1-1: Model of an acknowledged mode enttiy 

An AM RLC entity delivers/receives the following RLC data PDUs: 

- AMD PDU; 

AMD PDU segment. 
An AM RLC entity delivers/receives the following RLC control PDU: 

- STATUS PDU. 

4.2.1 .3.2 Transmitting side 

When the transmitting side of an AM RLC entity forms AMD PDUs from RLC SDUs, it shall: 
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segment and/or concatenate the RLC SDUs so that the AMD PDUs fit within the total size of RLC PDU(s) indicated 
by lower layer at the particular transmission opportunity notified by lower layer. 

The transmitting side of an AM RLC entity supports retransmission of RLC data PDUs (ARQ): 

if the RLC data PDU to be retransmitted does not fit within the total size of RLC PDU(s) indicated by lower layer at 
the particular transmission opportunity notified by lower layer, the AM RLC entity can re- segment the RLC data 
PDU into AMD PDU segments; 

the number of re-segmentation is not limited. 

When the transmitting side of an AM RLC entity forms AMD PDUs from RLC SDUs received from upper layer or AMD 
PDU segments from RLC data PDUs to be retransmitted, it shall: 

include relevant RLC headers in the RLC data PDU. 

4.2.1 .3.3 Receiving side 

When the receiving side of an AM RLC entity receives RLC data PDUs, it shall: 

detect whether or not the RLC data PDUs have been received in duplication, and discard duplicated RLC data PDUs; 

reorder the RLC data PDUs if they are received out of sequence; 

detect the loss of RLC data PDUs at lower layers and request retransmissions to its peer AM RLC entity; 

reassemble RLC SDUs from the reordered RLC data PDUs and deliver the RLC SDUs to upper layer in sequence. 

At the time of RLC re-establishment, the receiving side of an AM RLC entity shall: 

if possible, reassemble RLC SDUs from the RLC data PDUs that are received out of sequence and deliver them to 
upper layer; 

discard any remaining RLC data PDUs that could not be reassembled into RLC SDUs; 

initialize relevant state variables and stop relevant timers. 

4.3 Services 

4.3.1 Services provided to upper layers 

The following services are provided by RLC to upper layer (i.e. RRC or PDCP): 
TM data transfer; 
UM data transfer; 
AM data transfer, including indication of successful delivery of upper layers PDUs. 

4.3.2 Services expected from lower layers 

The following services are expected by RLC from lower layer (i.e. MAC): 

data transfer; 

notification of a transmission opportunity, together with the total size of the RLC PDU(s) to be transmitted in the 
transmission opportunity; 

notification of HARQ delivery failure from the transmitting MAC entity. 
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4.4 Functions 

The following functions are supported by the RLC sub layer: 
transfer of upper layer PDUs; 

error correction through ARQ (only for AM data transfer); 

concatenation, segmentation and reassembly of RLC SDUs (only for UM and AM data transfer); 
re-segmentation of RLC data PDUs (only for AM data transfer); 
in sequence delivery of upper layer PDUs (only for UM and AM data transfer); 
duplicate detection (only for UM and AM data transfer); 
RLC SDU discard (only for UM and AM data transfer); 
RLC re-establishment; 
Protocol error detection and recovery. 

4.5 Data available for transmission 

For the purpose of MAC buffer status reporting, the UE shall consider the following as data available for transmission in 
the RLC layer: 

- RLC SDUs, or segments thereof, that have not yet been included in an RLC data PDU; 

- RLC data PDUs, or portions thereof, that are pending for retransmission (RLC AM). 

In addition, if a STATUS PDU has been triggered and the status prohibit timer is not running or has expired, the UE shall 
estimate the size of the STATUS PDU that will be transmitted in the next transmission opportunity, and consider this as 
data available for transmission in the RLC layer. 

5 Procedures 

5.1 Data transfer procedures 

5.1.1 TM data transfer 

Editor's note: It is intended to specify details regarding RLC PDU delivery to lower layer at the transmitter and RLC 
SDU delivery to upper layers at the receiver in this section (if the text in sub clause 4.2.1.1 is insufficient). 

5.1.2 UM data transfer 
5.1 .2.1 Transmit operations 
5.1.2.1.1 General 

When delivering a new UMD PDU to lower layer, the transmitting UM RLC entity shall: 
- set the SN of the UMD PDU to VT(US), and then increment VT(US) by one. 
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5.1.2.2 Receive operations 

5.1.2.2.1 General 

The receiving UM RLC entity shall maintain a reordering window according to state variable VR(UH) as follows: 

- a SN falls within the reordering window if (VR(UH) - UM_Window_Size) <= SN < VR(UH); 
a SN falls outside of the reordering window otherwise. 

When receiving an UMD PDU from lower layer, the receiving UM RLC entity shall: 

either discard the received UMD PDU or place it in the reception buffer (see sub clause 5.1.2.2.2); 

if the received UMD PDU was placed in the reception buffer: 

update state variables, reassemble and deliver RLC SDUs to upper layer and start/stop T_reordering as needed 
(see sub clause 5.1.2.2.3); 

When T_reordering expires, the receiving UM RLC entity shall: 

update state variables, reassemble and deliver RLC SDUs to upper layer and start T_reordering as needed (see sub 
clause 5.1.2.2.4). 

5.1 .2.2.2 Actions when an UIVID PDU is received from lower layer 

When an UMD PDU with SN = x is received from lower layer, the receiving UM RLC entity shall: 

- if VR(UR) < X < VR(UH) and the UMD PDU with SN = x has been received before; or 

- if ( VR(UH) - UM_Windo w_Size) <= x < VR(UR) : 

- discard the received UMD PDU; 

- otherwise: 

- place the received UMD PDU in the reception buffer. 

5.1 .2.2.3 Actions when an UMD PDU is placed in the reception buffer 

When an UMD PDU with SN = x is placed in the reception buffer, the receiving UM RLC entity shall: 
if X falls outside of the reordering window: 

- update VR(UH) to x+1; 

reassemble RLC SDUs from any UMD PDUs with SN that falls outside of the reordering window, remove RLC 
headers when doing so and deliver the reassembled RLC SDUs to upper layer in sequence if not delivered 
before; 

if VR(UR) falls outside of the reordering window: 

- set VR(UR) to ( VR(UH) - UM_Windo w_Size) ; 

- if the reception buffer contains an UMD PDU with SN = VR(UR): 

update VR(UR) to the SN of the first UMD PDU with SN > current VR(UR) that has not been received; 

reassemble RLC SDUs from any UMD PDUs with SN < updated VR(UR), remove RLC headers when doing so 
and deliver the reassembled RLC SDUs to upper layer in sequence if not delivered before; 

if T_reordering is running: 

- if VR(UX) <= VR(UR) ; or 

if VR(UX) falls outside of the reordering window: 
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stop and reset T_reordering; 

- set VR(UX) to NULL; 

if T_reordering is not running (includes the case when T_reordering is stopped due to actions above): 

- ifVR(UH)>VR(UR): 

start T_reordering; 

- set VR(UX) to VR(UH). 

5.1 .2.2.4 Actions when Treordering expires 

When T_reordering expires, the receiving UM RLC entity shall: 

- update VR(UR) to the SN of the first UMD PDU with SN >= VR(UX) that has not been received; 

reassemble RLC SDUs from any UMD PDUs with SN < updated VR(UR), remove RLC headers when doing so and 
deliver the reassembled RLC SDUs to upper layer in sequence if not delivered before; 

- ifVR(UH)>VR(UR): 

start T_reordering; 

- set VR(UX) to VR(UH); 
otherwise: 

- set VR(UX) to NULL. 

Editor's note: It is intended to specify details regarding RLC PDU generation and delivery to lower layer at the 
transmitter and RLC PDU reordering and loss detection (and duplicate detection if needed), RLC 
SDU reassembly and delivery to upper layers at the receiver in this section. 

5.1.3 AM data transfer 
5.1 .3.1 Transnnit operations 

5.1.3.1.1 General 

The transmitting side of an AM RLC entity shall prioritize transmission of RLC control PDUs over RLC data PDUs. The 
transmitting side of an AM RLC entity shall prioritize retransmission of RLC data PDUs over transmission of new AMD 
PDUs. 

The transmitting side of an AM RLC entity shall maintain a transmitting window according to state variables VT(A) and 
VT(MS) as follows: 

a SN falls within the transmitting window if VT(A) <= SN < VT(MS); 

a SN falls outside of the transmitting window otherwise. 

The transmitting side of an AM RLC entity shall not deliver to lower layer any RLC data PDU whose SN falls outside of 
the transmitting window. 

When delivering a new AMD PDU to lower layer, the transmitting side of an AM RLC entity shall: 

- set the SN of the AMD PDU to VT(S), and then increment VT(S) by one. 

The transmitting side of an AM RLC entity can receive a positive acknowledgement (confirmation of successful reception 
by its peer AM RLC entity) for a RLC data PDU by the following: 

- STATUS PDU from its peer AM RLC entity. 
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When receiving a positive acknowledgement for an AMD PDU with SN = VT(A), the transmitting side of an AM RLC 
entity shall: 

if positive acknowledgements have been received for all other AMD PDUs whose SN fall within the range VT(A) <= 
SN < VT(S), set VT(A) equal to VT(S); 

otherwise, set VT( A) equal to the SN of the AMD PDU with the smallest SN, whose SN falls within the range VT( A) 
<= SN < VT(S) and for which a positive acknowledgment has not been received yet. 

if positive acknowledgements have been received for all AMD PDUs associated with a transmitted RLC SDU, send 
an indication to the upper layers of successful delivery of the RLC SDU. 

5.1.3.2 Receive operations 

5.1.3.2.1 General 

The receiving side of an AM RLC entity shall maintain a receiving window according to state variables VR(R) and 
VR(MR) as follows: 

- a SN falls within the receiving window if VR(R) <= SN < VR(MR); 
a SN falls outside of the receiving window otherwise. 

When receiving a RLC data PDU from lower layer, the receiving side of an AM RLC entity shall: 

either discard the received RLC data PDU or place it in the reception buffer (see sub clause 5.1 .3.2.2); 

if the received RLC data PDU was placed in the reception buffer: 

update state variables, reassemble and deliver RLC SDUs to upper layer and start/stop T_reordering as needed 
(see sub clause 5.1.3.2.3). 

When T_reordering expires, the receiving side of an AM RLC entity shall: 

update state variables and start T_reordering as needed (see sub clause 5.1.3.2.4). 

5.1 .3.2.2 Actions when a RLC data PDU is received from lower layer 

When a RLC data PDU is received from lower layer, where the RLC data PDU contains byte segment numbers y to z of an 
AMD PDU with SN = x, the receiving side of an AM RLC entity shall: 

if X falls outside of the receiving window; or 

if byte segment numbers y to z of the AMD PDU with SN = x have been received before: 

discard the received RLC data PDU; 
otherwise: 

place the received RLC data PDU in the reception buffer; 

if some byte segments of the AMD PDU contained in the RLC data PDU have been received before: 
discard the duplicate byte segments. 

5.1 .3.2.3 Actions when a RLC data PDU is placed in the reception buffer 

When a RLC data PDU with SN = x is placed in the reception buffer, the receiving side of an AM RLC entity shall: 

if all byte segments of the AMD PDU with SN = VR(MS) are received: 

update VR(MS) to the SN of the first AMD PDU with SN > current VR(MS) for which not all byte segments 
have been received; 

- ifx = VR(R): 
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if all byte segments of the AMD PDU with SN = VR(R) are received: 

update VR(R) to the SN of the first AMD PDU with SN > current VR(R) for which not all byte segments 
have been received; 

update VR(MR) to the updated VR(R) + AM_Window_Size; 

reassemble RLC SDUs from any byte segments of AMD PDUs with SN that falls outside of the receiving 
window and in-sequence byte segments of the AMD PDU with SN = VR(R), remove RLC headers when doing 
so and deliver the reassembled RLC SDUs to upper layer in sequence if not delivered before; 

- ifx>=VR(H) 

update VR(H) to x+ 1; 
if T_reordering is running: 

- ifVR(X) = VR(R);or 

if VR(X) falls outside of the receiving window: 
stop and reset T_reordering; 

- set VR(X) to NULL; 

if T_reordering is not running (includes the case T_reordering is stopped due to actions above): 

- iftheVR(H)>VR(R): 

start T_reordering; 

- set VR(X) to VR(H). 

5.1 .3.2.4 Actions when T_reordering expires 

When T_reordering expires, the receiving side of an AM RLC entity shall: 

update VR(MS) to the SN of the first AMD PDU with SN >= VR(X) for which not all byte segments have been 
received; 

- ifVR(H)>VR(MS): 

start T_reordering; 

- setVR(X)toVR(H); 
otherwise: 

- set VR(X) to NULL. 

5.2 ARQ procedures 

ARQ procedures are only performed by an AM RLC entity. 

5.2.1 Retransmission 

The transmitting side of an AM RLC entity can receive a negative acknowledgement (notification of reception failure by 
its peer AM RLC entity) for an AMD PDU or a portion of an AMD PDU by the following: 

- STATUS PDU from its peer AM RLC entity; 

HARQ delivery failure from the transmitting MAC entity. 

When receiving a negative acknowledgement for an AMD PDU or a portion of an AMD PDU by a STATUS PDU from 
its peer AM RLC entity, the transmitting side of the AM RLC entity shall: 
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- if the SN of the corresponding AMD PDU falls within the range VT(A) <= SN < VT(S): 

consider the AMD PDU or the portion of the AMD PDU for which a negative acknowledgement was received 
for retransmission. 

When receiving a negative acknowledgement for an AMD PDU or a portion of an AMD PDU by HARQ delivery failure 
notification from the transmitting MAC entity, the transmitting side of the AM RLC entity may: 

- if the SN of the corresponding AMD PDU falls within the range VT(A) <= SN < VT(S): 

consider the AMD PDU or the portion of the AMD PDU for which a negative acknowledgement was received 
for retransmission. 

When an AMD PDU or a portion of an AMD PDU is considered for retransmission, the transmitting side of the AM RLC 
entity shall: 

if it is considered for retransmission for the first time: 

- set the RETX_COUNT associated with the AMD PDU to zero; 

- else, if it or a portion of it has been delivered to lower layers for transmission since the last increment of 
RETX_COUNT or RETX_COUNT = 0: 

- increment the RETX_COUNT; 

- if RETX_COUNT = Max_Retx_Threshold: 

- indicate to upper layers that max retransmission has been reached. 

When retransmitting an AMD PDU, the transmitting side of an AM RLC entity shall: 

if the AMD PDU can entirely fit within the total size of RLC PDU(s) indicated by lower layer at the particular 
transmission opportunity, deliver the AMD PDU as it is except for the P field (the P field should be set according to 
sub clause 5.2.2); 

otherwise, segment the AMD PDU and form a new AMD PDU segment which will fit within the total size of RLC 
PDU(s) indicated by lower layer at the particular transmission opportunity. 

When retransmitting a portion of an AMD PDU, the transmitting side of an AM RLC entity shall: 

segment the portion of the AMD PDU as necessary and form a new AMD PDU segment which will fit within the 
total size of RLC PDU(s) indicated by lower layer at the particular transmission opportunity. 

When forming a new AMD PDU segment, the transmitting side of an AM RLC entity shall: 

- only map the Data field of the original AMD PDU to the Data field of the new AMD PDU segment; 
set the header of the new AMD PDU segment in accordance with the description in sub clause 6.; 

- set the P field according to sub clause 5.2.2. 

5.2.2 Polling 

An AM RLC entity can poll its peer AM RLC entity in order to trigger STATUS reporting at the peer AM RLC entity. 
Triggers to initiate polling include: 

- Transmission of last data in the buffer: 

- The transmitting side of an AM RLC entity shall set the P field of an RLC data PDU to " 1 " if both the 
transmission buffer and the retransmission buffer becomes empty (excluding transmitted RLC data PDU 
awaiting for acknowledgements) after the transmission of the RLC data PDU; 

- Expiry of poll retransmit timer: 

The transmitting side of an AM RLC entity shall: 
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- upon delivering a RLC data PDU with the P field set to " 1 " to lower layer; 

if T_poll_retransmit is not running: 

- start T_poll_retransniit; 

- store the SN = VT(S) - 1 in memory; 

- else: 

- restart T_poll_retransmit; 

- replace the stored SN in memory with the SN = VT(S) - 1. 

- stop T_poll_retransmit when it receives either a positive or negative acknowledgement for the 
corresponding RLC data PDU with the SN it stored in memory; 

when T_poll_retransmit expires: 

- if both the transmission buffer and the retransmission buffer are empty (excluding transmitted RLC data 
PDU awaiting for acknowledgements): 

- consider the AMD PDU with SN = VT(S) - 1 for retransmission; 

- set the P field of the RLC data PDU to be transmitted in the next transmission opportunity to T; 

- else: 

- set the P field of the RLC data PDU to be transmitted in the next transmission opportunity to T. 

- Every Poll_PDU PDUs: 

- The transmitting side of an AM RLC entity shall: 

- maintain a counter PDU_WITHOUT_POLL, which is initially set to 0; 

- increment PDU_WITHOUT_POLL by one for every new AMD PDU that it forms; 

- set the P field of an AMD PDU that it forms to T when PDU_WITHOUT_POLL = Poll_PDU; 

- reset PDU_WITHOUT_POLL to when it delivers to lower layer a RLC data PDU whose P field is set to 
T. 

- Every Poll_Byte bytes: 

The transmitting side of an AM RLC entity shall: 

- maintain a counter B YTE_WITHOUT_POLL, which is initially set to 0; 

- increment B YTE_WITHOUT_POLL for every new byte of Data field element that it maps to the Data field 
of an AMD PDU; 

- set the P field of an AMD PDU that it forms to T when BYTE_WITHOUT_POLL >= Poll_Byte; 

- reset B YTE_WITHOUT_POLL to when it delivers to lower layer a RLC data PDU whose P field is set to 
T. 

Editor's note: Whether or not the polling trigger 'Every Poll_PDU PDUs' and 'Every Poll_Byte bytes' are 
configurable or not is FES. It has been decided that other polling triggers are always enabled. 

5.2.3 Status reporting 

An AM RLC entity sends STATUS PDUs to its peer AM RLC entity in order to provide positive and/or negative 
acknowledgements of RLC PDUs (or portions of them). 

RRC configures whether or not the status prohibit function is to be used for an AM RLC entity. 
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Triggers to initiate STATUS reporting include: 

Polling from its peer AM RLC entity: 

The receiving side of an AM RLC entity shall trigger a STATUS report when it receives a RLC data PDU with 
the P field set to " 1 " and the HARQ reordering of the corresponding RLC data PDU is completed. 

Detection of reception failure of an RLC data PDU: 

The receiving side of an AM RLC entity shall trigger a STATUS report when T_reordering expires. 

NOTE: The expiry of T_reordering triggers both VR(MS) to be updated and a STATUS report to be triggered, but 
the STATUS report shall be triggered after VR(MS) is updated. 

When STATUS reporting has been triggered, the receiving side of an AM RLC entity shall: 

if T_status_prohibit is not running: 

at the first transmission opportunity indicated by lower layer, construct a STATUS PDU and deliver it to lower 
layer; 

else: 

at the first transmission opportunity indicated by lower layer after T_status_prohibit expires, construct a single 
STATUS PDU even if status reporting was triggered several times while T_status_prohibit was running and 
deliver it to lower layer; 

When a STATUS PDU has been delivered to lower layer, the receiving side of an AM RLC entity shall: 

start T_status_prohibit. 

When constructing a STATUS PDU, the AM RLC entity shall: 

- for the AMD PDUs with SN such that VR(R) <= SN < VR(MS) that has not been completely received yet, in 
increasing SN order, starting with SN = VR(R) up to the SN for which the resulting STATUS PDU fits to the total 
size of RLC PDU(s) indicated by lower layer: 

- if no byte segments have been received yet for an AMD PDU: 

- include in the STATUS PDU a NACK_SN which is set to the SN of the AMD PDU; 

- else 

- include in the STATUS PDU a set of NACK_SN, SOstart and SOend for each consecutive byte segments 
of the AMD PDU that has not been received yet. 

set the ACK_SN to the SN of the next not completely received AMD PDU which is not indicated with a 
NACK_SN in the resulting STATUS PDU. 



5.3 SDU discard procedures 



When indicated from upper layer (i.e. PDCP) to discard a particular RLC SDU, the transmitting side of an AM RLC entity 
or the transmitting UM RLC entity shall discard the indicated RLC SDU if no segment of the RLC SDU has been mapped 
to a RLC data PDU yet. 

5.4 Re-establishment procedure 

RLC re-establishment is performed upon request by RRC, and the function is applicable for AM and UM RLC entities. 

When RRC indicates that an RLC entity should be re-established, the RLC entity shall: 

if it is a receiving UM RLC entity: 

when possible, reassemble RLC SDUs from UMD PDUs with SN < VR(UH), remove RLC headers when doing 
so and deliver the reassembled RLC SDUs to upper layer if not delivered before; 
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discard all remaining UMD PDUs; 

if it is a transmitting UM RLC entity: 

- discard all RLC SDUs; 

if it is an AM RLC entity: 

when possible, reassemble RLC SDUs from any byte segments of AMD PDUs with SN < VR(MR) in the 
receiving side, remove RLC headers when doing so and deliver the reassembled RLC SDUs to upper layer if not 
delivered before; 

discard the remaining AMD PDUs and byte segments of AMD PDUs in the receiving side; 

discard all RLC SDUs and AMD PDUs in the transmitting side; 

discard all RLC control PDUs. 
stop and reset all timers; 
reset all state variables to their initial values. 

5.5 Handling of unknown, unforeseen and erroneous protocol 
data 

Editor's note: Everything is FES regarding this section, but it is intended to specify necessary details as discussions 
proceed. 

6 Protocol data units, formats and parameters 

6.1 Protocol data units 

RLC PDUs can be categorized into RLC data PDUs and RLC control PDUs. RLC data PDUs in sub clause 6.1.1 are used 
by TM, UM and AM RLC entities to transfer upper layer PDUs (i.e. RLC SDUs). RLC control PDUs in sub clause 6.1.2 
are used by AM RLC entity to perform ARQ procedures. 

6.1.1 RLC data PDU 

a) TMD PDU 

TMD PDU is used to transfer upper layer PDUs by a TM RLC entity. 

b) UMD PDU 

UMD PDU is used to transfer upper layer PDUs by an UM RLC entity. 

c) AMD PDU 

AMD PDU is used to transfer upper layer PDUs by an AM RLC entity. It is used when the AM RLC entity transmits 
(part of) the RLC SDU for the first time, or when the AM RLC entity retransmits an AMD PDU without having to 
perform re-segmentation. 

d) AMD PDU segment 

AMD PDU segment is used to transfer upper layer PDUs by an AM RLC entity. It is used when the AM RLC entity 
needs to retransmit an AMD PDU segment or an AMD PDU with the need to perform re-segmentation. 

6.1.2 RLC control PDU 

a) STATUS PDU 
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STATUS PDU is used by the receiving AM RLC entity to inform the transmitting AM RLC entity about AMD PDUs 
that are received successfully, and AMD PDUs that are detected to be lost by the receiving AM RLC entity. 

6.2 Formats and parameters 

The formats of RLC PDUs are described in sub clause 6.2.1 and their parameters are described in sub clause 6.2.2. 

6.2.1 Formats 

6.2.1.1 General 

RLC PDU is a bit string. In the figures in sub clause 6.2. L2 to 6.2. L6, bit strings are represented by tables in which the 
first and most significant bit is the left most bit of the first line of the table, the last and least significant bit is the rightmost 
bit of the last line of the table, and more generally the bit string is to be read from left to right and then in the reading order 
of the lines. 

RLC SDUs are bit strings that are byte aligned (i.e. multiple of 8 bits) in length. An RLC SDU is included into an RLC 
PDU from first bit onward. 

6.2.1.2 TMDPDU 

TMD PDU consists only of a Data field and does not consist of any RLC headers. 

I 1 1 1 1 1 1 1 1 



Data Oct 1 

Oct N 



Figure 6.2.1.2-1: TMD PDU 

6.2.1.3 UMDPDU 

UMD PDU consists of a Data field and an UMD PDU header. 

UMD PDU header consists of a fixed part (fields that are present for every UMD PDU) and an extension part (fields that 
are present for an UMD PDU when necessary). The fixed part of the UMD PDU header itself is byte aligned and consists 
of a FI, an E and a SN. The extension part of the UMD PDU header itself is byte aligned and consists of E(s) and LI(s). 

An UM RLC entity is configured by RRC to use either a 5 bit SN or a 10 bit SN. When the 5 bit SN is configured, the 
length of the fixed part of the UMD PDU header is one byte. When the 10 bit SN is configured, the fixed part of the UMD 
PDU header is identical to the fixed part of the AMD PDU header, except for D/C, RF and P fields all being replaced with 
Rl fields. The extension part of the UMD PDU header is identical to the extension part of the AMD PDU header 
(regardless of the configured SN size). 

An UMD PDU header consists of an extension part only when more than one Data field elements are present in the UMD 
PDU, in which case an E and a LI are present for every Data field element except the last. Furthermore, when an UMD 
PDU header consists of an odd number of LI(s), four padding bits follow after the last LL 
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Figure 6.2.1.3-1 : UMD PDU with 5 bit SN (No LI) 
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Figure 6.2.1.3-2: UMD PDU witli 10 bit SN (No LI) 



6.2.1.4 



AMD PDU 



AMD PDU consists of a Data field and an AMD PDU header. 

AMD PDU header consists of a fixed part (fields that are present for every AMD PDU) and an extension part (fields that 
are present for an AMD PDU when necessary). The fixed part of the AMD PDU header itself is byte aligned and consists 
of a D/C, a RF, a P, a Fl, an E and a SN. The extension part of the AMD PDU header itself is byte aligned and consists of 
E(s) and LI(s). 

An AMD PDU header consists of an extension part only when more than one Data field elements are present in the AMD 
PDU, in which case an E and a LI are present for every Data field element except the last. Furthermore, when an AMD 
PDU header consists of an odd number of LI(s), four padding bits follow after the last LI. 
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Figure 6.2.1.4-1: AMD PDU (No LI) 
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Figure 6.2.1.4-2: AMD PDU (Odd number of Lis, i.e. K = 1, 3, 5, ...) 
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Figure 6.2.1.4-3: AMD PDU (Even number of Lis, i.e. K = 2, 4, 6, ...) 
6.2.1 .5 AMD PDU segment 

AMD PDU segment consists of a Data field and an AMD PDU segment header. 

AMD PDU segment header consists of a fixed part (fields that are present for every AMD PDU segment) and an extension 
part (fields that are present for an AMD PDU segment when necessary). The fixed part of the AMD PDU segment header 
itself is byte aligned and consists of a D/C, a RF, a P, a FI, an E, a SN, a LSF and a SO. The extension part of the AMD 
PDU segment header itself is byte aligned and consists of E(s) and LI(s). 

An AMD PDU segment header consists of an extension part only when more than one Data field elements are present in 
the AMD PDU segment, in which case an E and a LI are present for every Data field element except the last. Furthermore, 
when an AMD PDU segment header consists of an odd number of LI(s), four padding bits follow after the last LI. 
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Figure 6.2.1.5-1: AMD PDU segment (No LI) 
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Figure 6.2.1.5-2: AMD PDU segment (Odd number of Lis, i.e. K = 1, 3, 5, ...) 
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Figure 6.2.1.5-3: AMD PDU segment (Even number of Lis, i.e. K = 2, 4, 6, ...) 
6.2.1.6 STATUS PDU 

STATUS PDU consists of a STATUS PDU payload and a RLC control PDU header. 

RLC control PDU header consists of a D/C and a CPT field. 

The STATUS PDU payload starts from the first bit following the RLC control PDU header, and it consists of one 
ACK_SN and one El, zero or more sets of a NACK_SN, an El and an E2, and possibly a set of a SOstart and a SOend for 
each NACK_SN. When necessary one to seven padding bits are included in the end of the STATUS PDU to achieve octet 
alignment. 



D/C 


CPT ACK_SN 


ACK_SN El 


NACK_SN 




El E2 NACK_SN 


NACK_SN El E2 


SOstart 


SOstart SOend 


SOend 


SOend NACK_SN 


... 



Oct 1 
Oct 2 
Oct 3 
Oct 4 
Oct 5 
Oct 6 
Oct? 
Oct 8 
Oct 9 



Figure 6.2.1.6-1: STATUS PDU 



6.2.2 Parameters 



6.2.2.1 



General 



In the definition of each field in sub clauses 6.2.2.2 to 6.2.2.19, the bits in the parameters are represented in which the first 
and most significant bit is the left most bit and the last and least significant bit is the rightmost bit. Unless mentioned 
otherwise, integers are encoded in standard binary encoding for unsigned integers. 
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6.2.2.2 Data field 

Data field elements are mapped to the Data field in the order which they arrive to the RLC entity at the transmitter. 

For TMD PDU, UMD PDU and AMD PDU: 

The granularity of the Data field size is one byte; 

The maximum Data field size is the maximum TB size minus the sum of minimum MAC PDU header size and 
minimum RLC PDU header size. 

For TMD PDU: 

- Only one RLC SDU can be mapped to the Data field of one TMD PDU. 

For UMD PDU, AMD PDU and AMD PDU segment: 

Either of the following can be mapped to the Data field of one UMD PDU, AMD PDU or AMD PDU segment: 

Zero RLC SDU segments and one or more RLC SDUs; 

One or two RLC SDU segments and zero or more RLC SDUs; 

RLC SDU segments are either mapped to the beginning or the end of the Data field; 

When there are two RLC SDU segments, they belong to different RLC SDUs. 

6.2.2.3 Sequence Number (SN) field 

Length: 10 bits for AMD PDU, AMD PDU segments and STATUS PDUs. 5 bits or 10 bits (configurable) for UMD PDU. 

The SN field indicates the sequence number of the corresponding UMD or AMD PDU. For an AMD PDU segment, the 
SN field indicates the sequence number of the original AMD PDU from which the AMD PDU segment was constructed 
from. The sequence number is incremented by one for every UMD or AMD PDU. 

6.2.2.4 Extension bit (E) field 

Length: 1 bit. 

The E field indicates whether Data field follows or a set of E field and LI field follows. The interpretation of the E field is 
provided in Table 6.2.2.4-1 and Table 6.2.2.4-2. 

Table 6.2.2.4-1 : E field interpretation (for E field in the fixed part of the header) 



Value 


Description 





Data field follows from the octet following the fixed part of the header 


1 


A set of E field and LI field follows from the octet following the fixed part of the header 



Table 6.2.2.4-2: E field interpretation (for E field in the extension part of the header) 



Value 


Description 





Data field follows from the octet following the LI field following this E field 


1 


A set of E field and LI field follows from the bit following the LI field following this E field 



6.2.2.5 Length Indicator (LI) field 

Length: 1 1 bits. 



ETSI 



3GPP TS 36.322 version 8.2.0 Release 8 



28 



ETSI TS 136 322 V8.2.0 (2008-11) 



The LI field indicates the length in bytes of the corresponding Data field element present in the AMD PDU. The first LI 
present in the AMD PDU header corresponds to the first Data field element present in the Data field of the AMD PDU, the 
second LI present in the AMD PDU header corresponds to the second Data field element present in the Data of the AMD 
PDU, and so on. 

6.2.2.6 Framing Info (Fl) field 

Length: 2 bits. 

The FI field indicates whether a RLC SDU is segmented at the beginning and/or at the end of the Data field. Specifically, 
the FI field indicates whether the first byte of the Data field corresponds to the first byte of a RLC SDU, and whether the 
last byte of the Data field corresponds to the last byte of a RLC SDU. The interpretation of the FI field is provided in Table 
6.2.2.6-1. 

Table 6.2.2.6-1 : FI field interpretation 



Value 


Description 


00 


First byte of the Data field corresponds to the first byte of a RLC SDU. 
Last byte of the Data field corresponds to the last byte of a RLC SDU. 


01 


First byte of the Data field corresponds to the first byte of a RLC SDU. 
Last byte of the Data field does not correspond to the last byte of a RLC SDU. 


10 


First byte of the Data field does not correspond to the first byte of a RLC SDU. 
Last byte of the Data field corresponds to the last byte of a RLC SDU. 


11 


First byte of the Data field does not correspond to the first byte of a RLC SDU. 
Last byte of the Data field does not correspond to the last byte of a RLC SDU. 



6.2.2.7 Segment Offset (SO) field 

Length: 15 bits. 

The SO field indicates the position of the AMD PDU segment in bytes within the original AMD PDU. Specifically, the 
SO field indicates the position within the Data field of the original AMD PDU to which the first byte of the Data field of 
the AMD PDU segment corresponds to. 



6.2.2.8 

Length: 1 bit. 



Last Segment Flag (LSF) field 



The LSF field indicates whether or not the last byte of the AMD PDU segment corresponds to the last byte of an AMD 
PDU. The interpretation of the LSF field is provided in Table 6.2.2.8-1. 

Table 6.2.2.8-1 : LSF field interpretation 



Value 


Description 





Last byte of the AMD PDU segment does not correspond to the last byte of an AMD PDU. 


1 


Last byte of the AMD PDU segment corresponds to the last byte of an AMD PDU. 



6.2.2.9 

Length: 1 bit. 



Data/Control (D/C) field 



The D/C field indicates whether the RLC PDU is a RLC data PDU or RLC control PDU. The interpretation of the D/C 
field is provided in Table 6.2.2.9-1. 
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Table 6.2.2.9-1: D/C field interpretation 



Value 


Description 





Control PDU 


1 


Data PDU 



6.2.2.10 Re-segmentation Flag (RF) field 

Length: 1 bit. 

The RF field indicates whether the RLC PDU is an AMD PDU or AMD PDU segment. The interpretation of the RF field 
is provided in Table 6.2.2.10-1. 

Table 6.2.2.10-1 : RF field interpretation 



Value 


Description 





AMD PDU 


1 


AMD PDU segment 



6.2.2.11 Polling bit (P) field 

Length: 1 bit. 

The P field indicates whether or not the transmitting side of an AM RLC entity requests a STATUS report from its peer 
AM RLC entity. The interpretation of the P field is provided in Table 6.2.2.11-1. 

Table 6.2.2.11-1: P field interpretation 



Value 


Description 





Status report not requested 


1 


Status report is requested 



6.2.2.12 Reserved 1 (R1) field 

Length: 1 bit. 

The Rl field is a reserved field for this release of the protocol. The transmitting entity shall set the Rl field to "0", and the 
receiving entity shall ignore the Rl field. 



6.2.2.13 Control PDU Type (CPT) field 

Length: 3 bits. 

The CPT field indicates the type of the RLC control PDU. The interpretation of the CPT field is provided in Table 
6.2.2.13-1. 

Table 6.2.2.13-1 : CPT field interpretation 



Value 



Description 



000 



STATUS PDU 
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001-111 



Reserved 
(PDUs with this coding will be discarded by the receiving entity for this release of the protocol) 



6.2.2.14 Acknowledgement SN (ACK_SN) field 

Length: 10 bits. 

The ACK_SN field indicates the first SN of AMD PDU not completely received and not reported in the STATUS PDU. 
When the transmitting side of an AM RLC entity receives a STATUS PDU, it interprets that all AMD PDUs up to but not 
including the AMD PDU with SN = ACK_SN have been received by its peer AM RLC entity, excluding those AMD 
PDUs indicated in the STATUS PDU with NACK_SN and portions of AMD PDUs indicated in the STATUS PDU with 
NACK_SN, SOstart and SOend. 

6.2.2.15 Extension bit 1 (El) field 

Length: 1 bit. 

The El field indicates whether or not a set of NACK_SN, El and E2 follows. The interpretation of the El field is provided 
in Table 6.2.2.15-1. 

Table 6.2.2.15-1: El field interpretation 



Value 


Description 





A set of NACK_SN, El and E2 does not follow. 


1 


A set of NACK_SN, El and E2 follows. 



6.2.2.16 Negative Acknowledgement SN (NACK_SN) field 

Length: 10 bits. 

The NACK_SN field indicates the SN of the AMD PDU (or portions of it) that has been detected as lost at the receiving 
side of the AM RLC entity. 

6.2.2.17 Extension bit 2 (E2) field 

Length: 1 bit. 

The E2 field indicates whether or not a set of SOstart and SOend follows. The interpretation of the E2 field is provided in 
Table 6.2.2.17-1. 

Table 6.2.2.17-1 : E2 field interpretation 



Value 


Description 





A set of SOstart and SOend does not follow for this NACK_SN. 


1 


A set of SOstart and SOend follows for this NACK_SN. 



6.2.2.18 SO start (SOstart) field 

Length: 15 bits. 

The SOstart field (together with the SOend field) indicates the portion of the AMD PDU with SN = NACK_SN (the 
NACK_SN for which the SOstart is related to) that has been detected as lost at the receiving side of the AM RLC entity. 
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Specifically, the SOstart field indicates the position of the first byte of the portion of the AMD PDU in bytes within the 
Data field of the AMD PDU. 

6.2.2.19 SO end (SOend) field 

Length: 15 bits. 

The SOend field (together with the SOstart field) indicates the portion of the AMD PDU with SN = NACK_SN (the 
NACK_SN for which the SOend is related to) that has been detected as lost at the receiving side of the AM RLC entity. 
Specifically, the SOend field indicates the position of the last byte of the portion of the AMD PDU in bytes within the 
Data field of the AMD PDU. The special SOend value '111111111111111' is used to indicate that the missing portion of 
the AMD PDU includes all bytes to the last byte of the AMD PDU. 



Variables, constants and timers 



7.1 State variables 

This sub clause describes the state variables used in AM and UM entities in order to specify the RLC protocol. The state 
variables defined in this subclause are normative. 

All state variables (i.e. VT(A), VT(MS), VT(S), VR(R), VR(MR), VR(X), VR(MS), VR(H), VT(US), VR(UR), VR(UX) 
and VR(UH)) are non-negative integers. 

All state variables related to AM data transfer (i.e. VT(A), VT(MS), VT(S), VR(R), VR(MR), VR(X), VR(MS) and 
VR(H)) can take values from to 1023. All arithmetic operations contained in the present document on state variables 
related to AM data transfer are affected by the AM modulus (i.e. final value = [value from arithmetic operation] modulo 
1024). 

All state variables related to UM data transfer (i.e. VT(US), VR(UR), VR(UX) and VR(UH)) can take values from to 
l^2[configuredUMSN field length] _ ly p^n arithmetic Operations contained in the present document on state variables related to UM 
data transfer are affected by the UM modulus (i.e. final value = [value from arithmetic operation] modulo 2^^°"^^^"^^^^^ ^^ 

field length] \ 

AMD PDUs and UMD PDUs are numbered integer sequence numbers (SN) cycling through the field: to 1023 for AMD 

PDU and to [2 t^^^fig^^^^ UM SN field length] _ ^^ ^^^ u^j3 pj^u^ 

When performing arithmetic comparisons of state variables or SN values, a modulus base shall be used. VT(A) and 
VR(R) shall be assumed as the modulus base at the transmitting side and receiving side of an AM RLC entity, 
respectively. This modulus base is subtracted from all the values involved, and then an absolute comparison is performed 
(e.g. VR(R) <= SN < VR(MR) is evaluated as [VR(R) - VR(R)] modulo 1024 <= [SN - VR(R)] modulo 1024 < [VR(MR) 
-VR(R)] modulo 1024). 

When performing arithmetic comparisons of state variables or SN values, a modulus base shall be used. VR(UH) - 
UM_Window_Size shall be assumed as the modulus base at the receiving side of an UM RLC entity. This modulus base 
is subtracted from all the values involved, and then an absolute comparison is performed (e.g. (VR(UH) - 
UM_Window_Size) <= SN < VR(UH) is evaluated as [(VR(UH) - UM_Window_Size) - (VR(UH) - 
UM_Window_Size)] modulo 2 t-^fig^^^^ ™ sn field length] ^^ ^3^ _ (VR(UH) - UM_Window_Size)] modulo 2[^°"fig^^^^ ™ sn 

field length] ^ [VR(UH) - (VR(UH) - UM_Wind0W_Size)] modulo 2[-"fig^^^d™SN field length] ^^ 

The transmitting side of each AM RLC entity shall maintain the following state variables: 

a) VT(A) - Acknowledgement state variable 

This state variable holds the value of the SN of the next AMD PDU for which a positive acknowledgment is to be received 
in-sequence, and it serves as the lower edge of the transmitting window). It is initially set to 0, and is updated whenever 
the AM RLC entity receives a positive acknowledgment for an AMD PDU with SN = VT(A). 

b) VT(MS) - Maximum send state variable 

This state variable equals VT(A) + AM_Window_Size, and it serves as the higher edge of the transmitting window. 



ETSI 



3GPP TS 36.322 version 8.2.0 Release 8 32 ETSI TS 136 322 V8.2.0 (2008-1 1) 

c) VT(S) - Send state variable 

This state variable holds the value of the SN to be assigned for the next newly generated AMD PDU. It is initially set to 0, 
and is updated whenever the AM RLC entity delivers an AMD PDU with SN = VT(S). 

The receiving side of each AM RLC entity shall maintain the following state variables: 

a) VR(R) - Receive state variable 

This state variable holds the value of the SN following the last in-sequence completely received AMD PDU, and it serves 
as the lower edge of the receiving window. It is initially set to 0, and is updated whenever the AM RLC entity receives an 
AMD PDU with SN = VR(R). 

b) VR(MR) - Maximum acceptable receive state variable 

This state variable equals VR(R) + AM_Window_Size, and it holds the value of the SN of the first AMD PDU that is 
beyond the receiving window. 

c) VR(X) - T_reordering state variable 

This state variable holds the value of the SN following the SN of the RLC data PDU which triggered T_reordering. It is 
initially set to NULL. 

d) VR(MS) - Maximum STATUS transmit state variable 

This state variable holds the highest possible value of the SN which can be indicated by ' ACK_SN' when a STATUS PDU 
needs to be constructed. It is initially set to 0. 

e) VR(H) - Highest received state variable 

This state variable holds the value of the SN following the SN of the RLC data PDU with the highest SN among received 
RLC data PDUs. It is initially set to 0. 

Each transmitting UM RLC entity shall maintain the following state variables: 

a) VT(US) 

This state variable holds the value of the SN to be assigned for the next newly generated UMD PDU. It is initially set to 0, 
and is updated whenever the UM RLC entity delivers an UMD PDU with SN = VT(US). 

Each receiving UM RLC entity shall maintain the following state variables: 

a) VR(UR) - UM receive state variable 

This state variable holds the value of the SN of the earliest UMD PDU that is still considered for reordering. It is initially 
set to 0. 

b) VR(UX) - UM T_reordering state variable 

This state variable holds the value of the SN following the SN of the UMD PDU which triggered T_reordering. It is 
initially set to NULL. 

c) VR(UH) - UM highest received state variable 

This state variable holds the value of the SN following the SN of the UMD PDU with the highest SN among received 
UMD PDUs. It is initially set to 0. 

7.2 Constants 

a) AM_Window_Size 

This constant is used by both the transmitting side and the receiving side of each AM RLC entity to calculate VT(MS) 
from VT(A), and VR(MR) from VR(R). AM_Window_Size = 512. 

b) UM_Window_Size 
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This constant is used by the receiving UM RLC entity to calculate VR(UMR) from VR(UR). UM_Window_Size =16 
when a 5 bit SN is configured and UM_Window_Size = 512 when a 10 bit SN is configured. 



7.3 Timers 

a) T_poll_retransmit 

This timer is used by the transmitting side of an AM RLC entity in order to retransmit a poll (see sub clause 5.2.2). 

b) T_reordering 

This timer is used by the receiving side of an AM RLC entity and receiving UM RLC entity in order to detect loss of RLC 
PDUs at lower layer (see sub clauses 5.12.2 and 5.1.3.2). If T_reordering is running, T_reordering shall not be started 
additionally, i.e. only one T_reordering is running at a given time. 

c) T_status_prohibit 

This timer is used by the receiving side of an AM RLC entity in order to prohibit transmission of a STATUS PDU (see sub 
clause 5.2.3). 

7.4 Configurable parameters 

a) Max_Retx_Threshold 

This parameter is used by the transmitting side of each AM RLC entity to limit the number of retransmissions of an AMD 
PDU (see subclause 5.2.1). 

b) PolLPDU 

This parameter is used by the transmitting side of each AM RLC entity for which the polling trigger 'Every Poll_PDU 
PDUs' has been configured (see subclause 5.2.2). 

c) PolLByte 

This parameter is used by the transmitting side of each AM RLC entity for which the polling trigger 'Every Poll_Byte 
bytes' has been configured (see subclause 5.2.2). 
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received, actions at T_reordering expiry and RLC SDU reassembly; 

T_and in subclause 5.1.3; 

Removed Editor's note which said that PDU loss detection should be 

after HARQ reordering; 

Clarified the description of the polling trigger "transmission of last 

data in the buffer"; 

Added description of STATUS PDU construction in sub clause 5.2.3 

and removed an Editor's note in this sub clause; 

IVIodified trigger for RLC SDU discard to "indication from PDCP"; 

Removed Editor's note on the type of PDUs to be specified; 

Removed Editor's notes regarding STATUS PDU piggybacking; 

Complete UIVID PDU headers captured and 2 new figures inserted 

for them, and removed Editor's note on UIVID PDU; 

Defined one STATUS PDU format with a new figure and an Editor's 

note, and removed old Editor's note in sub clause 6.2.1 .6; 

Added description of the R1 field, CPT field, ACK SN field. El field, 

NACK SN field, E2 field, SOstart field and SOend field. 

Added 7 state variables: VR(R-SO), VR(X), VR(X-SO), VR(MS), 

VR(UR), VR(UMR) and VR(UX); 

Constants Rx_Window_Size and Tx Window size were converged 

into one constant "Window_Size" of which the value is defined to half 

the SN space, and constants "AI\/l_Window_Size" and 

"UI\/l_Window_Size" were newly defined; 

Added 1 timer: T reordering. 






2007-1 1 


RAN2#60 


R2-075501 






Added definition for "byte segment"; 

Removed Editor's note which said that the SDU discard functionality 

may not be specified in RLC; 

Added missing description for RLC-UIVI receive operation (the case 

when UIVID PDU with SN that falls within the reordering window but 

not equal to VR(R) is received); 

Added missing description for RLC-AM receive operation (the case 

when only part of the received RLC data PDU is received in 

duplication); 

Added text related to updating state variable VR(MS); 

Added Editor's note that it has to be decided whether T_reordering 

can be triggered by a missing RLC data PDU for which status 

reporting has already been triggered once; 

Editorial clarification / corrections were made. 


1.1.1 


1.1.2 


2007-1 1 


RAN2#60 


R2-075502 






Added text related to updating state variable VR(MS); 
Editorial clarification / corrections were made. 


1.1.2 


1.1.3 


2007-1 1 


RAN2#60 


R2-075503 






Modified description of VR(MS) update procedure; 
Modified description of VR(X) / VR(X-SO) update procedure; 
Editorial corrections were made. 


1.1.3 


1.1.4 


2007-1 1 


RAN2#60 


R2-075504 






Added missing description with regards to RLC-AM receive 

operation; 

Added Editor's note on the delivery of RLC control PDUs; 

Editorial corrections were made. 


1.1.4 


1.1.5 


2007-1 1 


RAN2#60 


R2-074589 






v1 .1 .5 was endorsed by RAN WG2 as v1 .2.0. 


1.1.5 


1.2.0 


2007-1 1 


RAN #38 


RP-070918 






v1 .2.0 was stepped to v2.0.0 and presented to RAN plenary for 
approval. 


1.2.0 


2.0.0 


2007-12 


RAN #38 


- 






Approved at TSG RAN-38 and placed under change control 


2.0.0 


8.0.0 


2008-03 


RAN #39 


RP-080196 


0001 




CR0001 for TS 36.322 E-UTRA RLC: 

Added reference to TS 36.321 ; 

Clarified definition of 'byte segment'; 

Renamed 'Segmentation Info' to 'Framing Info'; 

Aligned texts to refer to 'upper layer' and 'lower layer' instead of 

RRC/PDCP and MAC; 

Specified that BCCH and DL CCCH is handled by RLC-TM; 

Added support for duplicate detection by receiving RLC UM entity;; 

Clarified that RLC SDUs should be delivered to upper layers in 

sequence; 

Modified description so that MAC indicates 'total size of RLC PDUs' 

together with notification of transmission opportunity instead of 'TB 

size'; 

Specified that RLC SDU discard is applied for RLC-AM and RLC 

UM, and introduced the detailed RLC SDU discard procedure; 

Renamed 'RLC reset' to 'RLC re-establishment', and introduced the 

detailed RLC re-establishment procedure; 

Removed Editor"s note on RLC flow control (flow control will not be 

supported by RLC); 

Restructured the texts on RLC AM and RLC UM receive operations, 

and added/modified the detailed descriptions; 

Added description on prioritization of data to transmit (control > data; 

retransmission > new data); 
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Removed the term STATUS transmitting window; 

Clarified that retransmission of negatively acknowledged data by 

STATUS PDU is mandatory and that retransmission of negatively 

acknowledged data by HARQ delivery failure is optional; 

Removed Editor"s note on retransmission prohibit (there will be no 

conditions where negatively acknowledged data shall not be 

retransmitted); 

Clarified description on polling trigger Transmission of last data in 

buffer'; 

Added new polling triggers 'Every Poll_PDU PDUs' and 'Every 

Poll_Byte Bytes', introduced their descriptions, and added an 

Editor"s note that their configurability is FFS; 

Added description on status reporting trigger 'detection of reception 

failure of an RLC data PDU'; 

Introduced description of the status prohibit function; 

Removed Editor"s note on the possibility to define more RLC control 

PDUs (no more RLC control PDUs will be defined); 

Clarified the 'most significant bit' and 'least significant bit' in an RLC 

PDU; 

Removed reference to bit numbers in RLC PDU; 

IVIodified the order of fields in the Ibyte UIVID PDU header; 

Removed Editor"s note on the order of fields in the AIVID PDU / AIVID 

PDU segment header (they are now confirmed); 

IVIodified definition of ACK_SN; 

Defined the special value of SOend; 

Added description on the UM modulus operation; 

Removed state variables VR(R-SO), VR(X-SO) and VR(UMR); 

Modified description/definition of state variables VR(MR), VR(X), 

VR(MS), VR(UR)andVR(UX); 

Introduced new state variables VR(H) and VR(UH) and their 

descriptions; 

Introduced new constants Poll_PDU and Poll_Byte and their 

descriptions; 

Clarified that only one T reordering will be running at one time for an 

RLC entity; 

Introduced new timer T_status_prohibit and its description; 

Editorial corrections were made. 






2008-05 


RAN #40 


RP-08041 1 


0002 


1 


Clarification on STATUS PDU size for BSR 


8.1.0 


8.2.0 




RAN #40 


RP-08041 1 


0003 


- 


Removal of Editor"s Note on updating of VR(MS) upon expiry of 
T reordering 


8.1.0 


8.2.0 




RAN #40 


RP-08041 1 


0004 


- 


Removal of STATUS receiving window 


8.1.0 


8.2.0 




RAN #40 


RP-08041 1 


0005 


- 


Duplicate detection in UM RLC 


8.1.0 


8.2.0 




RAN #40 


RP-08041 1 


0006 


- 


Correction to Polling Procedure 


8.1.0 


8.2.0 




RAN #40 


RP-08041 1 


0007 


- 


Miscellaneous corrections to TS 36.322 


8.1.0 


8.2.0 




RAN #40 


RP-08041 1 


0008 


- 


Small corrections to RLC 


8.1.0 


8.2.0 




RAN #40 


RP-08041 1 


0012 


- 


CR to 36.322 on correction to RLC PDU reassembly 


8.1.0 


8.2.0 




RAN #40 


RP-08041 1 


0015 


1 


36.322 CR on 'RLC retransmission count and addition of 
Configurable Parameters' 


8.1.0 


8.2.0 




RAN #40 


RP-08041 1 


0017 


- 


Service alignments with TS 36.323 (PDCP) 


8.1.0 


8.2.0 




RAN #40 


RP-08041 1 


0018 


- 


CR on the procedure to construct the STATUS PDU 
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